Session Start: Sat Jul 19 00:00:00 2014 Session Ident: #glitchpc [00:00] * Now talking in #glitchpc
[00:00] * Topic is 'Welcome to #glitchpc chat. Profanity, trolls, and impersonation are not welcome here. Street1 has become a Silent Keyboard. http://www.legacy.com/obituaries/savannah/obituary.aspx?page=lifestory&pid=139870551'
[00:00] * Set by jacky on Tue Mar 02 13:03:23
[02:23] * jamer (uid12136@mib-DEE87C23.irccloud.com) Quit (Quit: Connection closed for inactivity)
[02:50]<@BC_Programming> !w nanaimo BC
[02:51]<@BC_Programming> Thats better
[02:51]<@BC_Programming> Now to go get snacks
[04:55] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Client exited)
[04:56] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[04:59] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[05:18] * PCdoc (PCdoc@AFAE3A37.B19CBEC.EE292452.IP) has joined #glitchpc
[05:39] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[05:42] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[05:44] * PCdoc (PCdoc@AFAE3A37.B19CBEC.EE292452.IP) Quit (Connection reset by peer)
[07:27] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[07:30] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[08:22] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[08:25] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[09:16] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[09:19] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[09:51] * jamer (uid12136@mib-DEE87C23.irccloud.com) has joined #glitchpc
[10:10] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[10:13] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[11:05] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[11:08] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[11:59] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[12:02] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[12:42] * Craig_VPN (Mibbit@mib-F290140A.dynamic.platinum.ca) has joined #glitchpc
[12:44]<Craig_VPN> Hmmm even after my rsync Cron job, the http://gpcl.brokedcomputer.com/ still isnt updated?
[12:46] * Craig_VPN (Mibbit@mib-F290140A.dynamic.platinum.ca) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[12:53] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[12:56] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)
[13:59] * Tux2 (Tux2@mib-E1D082FA.pow-wy.client.bresnan.net) has joined #glitchpc
[14:26] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[14:28] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Quit: Bye)
[14:31]<Tux2> BC_Programming!
[14:31]<Tux2> http://forums.bukkit.org/threads/minigame-scheduler-help.292742/
[14:32]<Tux2> Have fun ranting on it. ;)
[14:34]<@BC_Programming> ahh nothing like completely untested X is not good for performance claims
[14:35]<@BC_Programming> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/concurrent/ConcurrentHashMap.java#907
[14:35]<@BC_Programming> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/HashMap.java#386
[14:36] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[14:36]<@BC_Programming> http://stackoverflow.com/questions/1378310/performance-concurrenthashmap-vs-hashmap
[14:37]<Tux2> lol, of course! Everyone just says to use a ConcurrentHashMap from the start.
[14:37]<Tux2> Especially for that type of volume
[14:38]<Tux2> That was one of the threads I found, but I couldn't find any numbers as far as performance went, which is why I conducted my little test to see just how much of a difference it made... I had to up the number to 10 Million just to MEASURE the difference!
[14:39]<@BC_Programming> yeah its pretty costly was clearly pulled out of thin air
[14:39]<@BC_Programming> the only real performance issues occur when being used across different threads too. But in that scenario, HashMap doesnt work properly to begin with
[14:40]<Tux2> Exactly!
[14:41]<Tux2> I love being able to refute claims like that. Here's the thing: I went into the test thinking: "I wonder if he's right... let's measure it just to see..." "Oh! Well, seems I was right, performance his is negligible."
[14:41]<Tux2> hit*
[14:42]<Tux2> I'm sure next he's going to pull the memory cost on me...
[15:00]<@BC_Programming> Another point you could raise is that it is not unexpected that the HashMap may need to be manipulated from an Async event such as AsyncPlayerChat or something
[15:01]<Tux2> lol, right?
[15:02]<@BC_Programming> I use ConcurrentDictionarys for pretty much everything in C#, though I also have a tendency to use separate threads for stuff so Its just a precaution
[15:03]<Tux2> Exactly!
[15:16] * Craig_VPN (Mibbit@mib-F290140A.dynamic.platinum.ca) has joined #glitchpc
[15:17]<Craig_VPN> And I am back,
[15:17]<Craig_VPN> :p
[15:17]<Tux2> yay!
[15:17]<Craig_VPN> How is everyone doing?
[15:17]<Craig_VPN> Oh hey Tux, any idea why my http://gpcl.brokedcomputer.com wont update past 10 days ago/
[15:18]<@BC_Programming> system time correct?
[15:18]<Tux2> Yeah, first thing to check
[15:18]<Craig_VPN> Yeah the server time is correct, or the day would be in the future.
[15:25]<Tux2> BC_Programming: well, I did the memory usage, and that had some surprising results...
[15:26]<Tux2> I measured the memory usage before and after I had created each hash map
[15:26]<Tux2> The difference is what I calculated the hashmap used. concurrent average over 5 runs: 44.6MB, regular: 13.4MB
[15:27]<@BC_Programming> Not that surprising, ConcurrentHashMap uses 16 buckets, I think the normal one only uses 4 but Im not sure about that
[15:28]<Tux2> Yeah
[15:28]<@BC_Programming> Personally I think using a different class because it uses less memory isnt a great reason overall unless the difference is really large
[15:28]<Tux2> Here's the interesting part: total memory used, averaged together for concurrent: 1349.6MB, regular: 1327.8MB
[15:29]<Tux2> Only a difference of 22MB, which I think is quite interesting...
[15:29]<Tux2> considering the base numbers were quite close in all tests
[15:30]<Tux2> My theory is Java cleaning up garbage from the random number generator or something while the hashmap is running
[15:30] * pottsi (Mibbit@pottsi.staff.mibbit.net) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[15:34]<Tux2> Either way, it's only an average of 3.12 bytes per entry for overhead, which is quite small
[15:35]<Tux2> I'm going to have to say, their argument about overhead, whether they pick memory used or performance is invalid at this point
[15:38]<Tux2> Next time an argument comes up about Concurrent or regular hash maps I'm going to ask them, "are you really quibbling over 0.0003 milliseconds and 3 bytes of data per entry?
[15:39]<Tux2> Just use concurrent and save yourself the headache."
[16:07] * Craig_VPN (Mibbit@mib-F290140A.dynamic.platinum.ca) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[17:31] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Client exited)
[17:32] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) has joined #glitchpc
[17:35] * Nat (nat@mib-7D0F5FD5.socal.res.rr.com) Quit (Ping timeout)